home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 19 / CU Amiga Magazine's Super CD-ROM 19 (1998)(EMAP Images)(GB)[!][issue 1998-02].iso / CUCD / Online / RFCs / rfc / rfc2038.txt < prev    next >
Text File  |  1996-10-29  |  23KB  |  620 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         D. Hoffman
  8. Request for Comments: 2038                                   G. Fernando
  9. Category: Standards Track                         Sun Microsystems, Inc.
  10.                                                                 V. Goyal
  11.                                                   Precept Software, Inc.
  12.                                                             October 1996
  13.  
  14.  
  15.                 RTP Payload Format for MPEG1/MPEG2 Video
  16.  
  17. Status of this Memo
  18.  
  19.    This document specifies an Internet standards track protocol for the
  20.    Internet community, and requests discussion and suggestions for
  21.    improvements.  Please refer to the current edition of the "Internet
  22.    Official Protocol Standards" (STD 1) for the standardization state
  23.    and status of this protocol.  Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    This memo describes a packetization scheme for MPEG video and audio
  28.    streams.  The scheme proposed can be used to transport such a video
  29.    or audio flow over the transport protocols supported by RTP.  Two
  30.    approaches are described. The first is designed to support maximum
  31.    interoperability with MPEG System environments.  The second is
  32.    designed to provide maximum compatibility with other RTP-encapsulated
  33.    media streams and future conference control work of the IETF.
  34.  
  35. 1. Introduction
  36.  
  37.    ISO/IEC JTC1/SC29 WG11 (also referred to as the MPEG committee) has
  38.    defined the MPEG1 standard (ISO/IEC 11172)[1] and the MPEG2 standard
  39.    (ISO/IEC 13818)[2].  This memo describes a packetization scheme to
  40.    transport MPEG video and audio streams using the Real-time Transport
  41.    Protocol (RTP), version 2 [3, 4].
  42.  
  43.    The MPEG1 specification is defined in three parts: System, Video and
  44.    Audio.  It is designed primarily for CD-ROM-based applications, and
  45.    is optimized for approximately 1.5 Mbits/sec combined data rates. The
  46.    video and audio portions of the specification describe the basic
  47.    format of the video or audio stream.  These formats define the
  48.    Elementary Streams (ES).  The MPEG1 System specification defines an
  49.    encapsulation of the ES that contains Presentation Time Stamps (PTS),
  50.    Decoding Time Stamps and System Clock references, and performs
  51.    multiplexing of MPEG1 compressed video and audio ES's with user data.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Hoffman, et. al.            Standards Track                     [Page 1]
  59.  
  60. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  61.  
  62.  
  63.    The MPEG2 specification is structured in a similar way. However, it
  64.    hasn't been restricted only to CD-ROM applications. The MPEG2 System
  65.    specification defines two system stream formats:  the MPEG2 Transport
  66.    Stream (MTS) and the MPEG2 Program Stream (MPS).  The MTS is tailored
  67.    for communicating or storing one or more programs of MPEG2 compressed
  68.    data and also other data in relatively error-prone environments. The
  69.    MPS is tailored for relatively error-free environments.
  70.  
  71.    We seek to achieve interoperability among 4 types of end-systems in
  72.    the following specification. The 4 types are:
  73.  
  74.         1. Transmitting Interworking Unit (TIU)
  75.  
  76.            Receives MPEG information from a native MTS system for
  77.            distribution over packet networks using a native RTP-based
  78.            system layer (such as an IP-based internetwork). Examples:
  79.            real-time encoder, MTS satellite link to Internet, video
  80.            server with MTS-encoded source material.
  81.  
  82.         2. Receiving Interworking Unit (RIU)
  83.  
  84.            Receives MPEG information in real time from an RTP-based
  85.            network for forwarding to a native MTS environment.
  86.            Examples: Internet-based video server to MTS-based cable
  87.            distribution plant.
  88.  
  89.         3. Transmitting Internet End-System (TAES)
  90.  
  91.            Transmits MPEG information generated or stored within the
  92.            internet end-system itself, or received from internet-based
  93.            computer networks.  Example: video server.
  94.  
  95.         4. Receiving Internet End-System (RAES)
  96.  
  97.            Receives MPEG information over an RTP-based internet for
  98.            consumption at the internet end-system or forwarding to
  99.            traditional computer network.  Example: desktop PC or
  100.            workstation viewing training video.
  101.  
  102.    Each of the 2 types of transmitters must work with each of the 2
  103.    types of receivers.  Because it is probable that the TAES, and
  104.    certain that the RAES, will be based on existing and planned
  105.    internet-connected computers, it is highly desirable for the
  106.    interoperable protocol to be based on RTP.
  107.  
  108.    Because of the range of applications that might employ MPEG streams,
  109.    we propose to define two payload formats.
  110.  
  111.  
  112.  
  113.  
  114. Hoffman, et. al.            Standards Track                     [Page 2]
  115.  
  116. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  117.  
  118.  
  119.    Much interest in the MPEG community is in the use of one of the MPEG
  120.    System encodings, and hence, in Section 2 we propose encapsulations
  121.    of MPEG1 System streams and MPEG2 Transport and Program Streams with
  122.    RTP.  This profile supports the full semantics of MPEG System and
  123.    offers basic interoperability among all four end-system types.
  124.  
  125.    When operating only among internet-based end-systems (i.e., TAES and
  126.    RAES) a payload format that provides greater compatibility with the
  127.    Internet architecture is desired, deferring some of the system issues
  128.    to other protocols being defined in the Internet community (such as
  129.    the MMUSIC WG).  In Section 3 we propose an encapsulation of
  130.    compressed video and audio data (referred to in MPEG documentation as
  131.    "Elementary Streams" (ES)) complying with either MPEG1 or MPEG2.
  132.    Here, neither of the System standards of MPEG1 or MPEG2 are utilized.
  133.    The ES's are directly encapsulated with RTP.
  134.  
  135.    Throughout this specification, we make extensive use of MPEG
  136.    terminology.  The reader should consult the primary MPEG references
  137.    for definitive descriptions of this terminology.
  138.  
  139. 2. Encapsulation of MPEG System and Transport Streams
  140.  
  141.    Each RTP packet will contain a timestamp derived from the sender's
  142.    90KHz clock reference.  This clock is synchronized to the system
  143.    stream Program Clock Reference (PCR) or System Clock Reference (SCR)
  144.    and represents the target transmission time of the first byte of the
  145.    packet payload.  The RTP timestamp will not be passed to the MPEG
  146.    decoder.  This use of the timestamp is somewhat different than
  147.    normally is the case in RTP, in that it is not considered to be the
  148.    media display or presentation timestamp. The primary purposes of the
  149.    RTP timestamp will be to estimate and reduce any network-induced
  150.    jitter and to synchronize relative time drift between the transmitter
  151.    and receiver.
  152.  
  153.    For MPEG2 Transport Streams the RTP payload will contain an integral
  154.    number of MPEG transport packets.  To avoid end system
  155.    inefficiencies, data from multiple small MTS packets (normally fixed
  156.    in size at 188 bytes) are aggregated into a single RTP packet.  The
  157.    number of transport packets contained is computed by dividing RTP
  158.    payload length by the length of an MTS packet (188).
  159.  
  160.    For MPEG2 Program streams and MPEG1 system streams there are no
  161.    packetization restrictions; these streams are treated as a packetized
  162.    stream of bytes.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Hoffman, et. al.            Standards Track                     [Page 3]
  171.  
  172. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  173.  
  174.  
  175. 2.1 RTP header usage
  176.  
  177.    The RTP header fields are used as follows:
  178.  
  179.         Payload Type: Distinct payload types should be assigned for
  180.           of MPEG1 System Streams, MPEG2 Program Streams and MPEG2
  181.           Transport Streams.  See [4] for payload type assignments.
  182.  
  183.         M bit:  Set to 1 whenever the timestamp is discontinuous
  184.           (such as might happen when a sender switches from one data
  185.           source to another). This allows the receiver and any
  186.           intervening RTP mixers or translators that are synchronizing
  187.           to the flow to ignore the difference between this timestamp
  188.           and any previous timestamp in their clock phase detectors.
  189.  
  190.         timestamp: 32 bit 90K Hz timestamp representing the target
  191.           transmission time for the first byte of the packet.
  192.  
  193. 3. Encapsulation of MPEG Elementary Streams
  194.  
  195.    The following ES types may be encapsulated directly in RTP:
  196.  
  197.         (a) MPEG1 Video (ISO/IEC 11172-2)
  198.         (b) MPEG2 Video (ISO/IEC 13818-2)
  199.         (c) MPEG1 Audio (ISO/IEC 11172-3)
  200.         (d) MPEG2 Audio (ISO/IEC 13818-3)
  201.  
  202.    A distinct RTP payload type is assigned to MPEG1/MPEG2 Video and
  203.    MPEG1/MPEG2 Audio, respectively. Further indication as to whether the
  204.    data is MPEG1 or MPEG2 need not be provided in the RTP or MPEG-
  205.    specific headers of this encapsulation, as this information is
  206.    available in the ES headers.
  207.  
  208.    Presentation Time Stamps (PTS) of 32 bits with an accuracy of 90 kHz
  209.    shall be carried in the fixed RTP header. All packets that make up a
  210.    audio or video frame shall have the same time stamp.
  211.  
  212. 3.1 MPEG Video elementary streams
  213.  
  214.    MPEG1 Video can be distinguished from MPEG2 Video at the video
  215.    sequence header, i.e. for MPEG2 Video a sequence_header() is followed
  216.    by sequence_extension().  The particular profile and level of MPEG2
  217.    Video (MAIN_Profile@MAIN_Level, HIGH_Profile@HIGH_Level, etc) are
  218.    determined by the profile_and_level_indicator field of the
  219.    sequence_extension header of MPEG2 Video.
  220.  
  221.    The MPEG bit-stream semantics were designed for relatively error-free
  222.    environments, and there is significant amount of dependency (both
  223.  
  224.  
  225.  
  226. Hoffman, et. al.            Standards Track                     [Page 4]
  227.  
  228. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  229.  
  230.  
  231.    temporal and spatial) within the stream such that loss of some data
  232.    make other uncorrupted data useless.  The format as defined in this
  233.    encapsulation uses application layer framing information plus
  234.    additional information in the RTP stream-specific header to allow for
  235.    certain recovery mechanisms.  Appendix 1 suggests several recovery
  236.    strategies based on the properties of this encapsulation.
  237.  
  238.    Since MPEG pictures can be large, they will normally be fragmented
  239.    into packets of size less than a typical LAN/WAN MTU.  The following
  240.    fragmentation rules apply:
  241.  
  242.         1. The MPEG Video_Sequence_Header, when present, will always
  243.            be at the beginning of an RTP payload.
  244.         2. An MPEG GOP_header, when present, will always be at the
  245.            beginning of the RTP payload, or will follow a
  246.            Video_Sequence_Header.
  247.         3. An MPEG Picture_Header, when present, will always be at the
  248.            beginning of a RTP payload, or will follow a GOP_header.
  249.  
  250.    Each ES header must be completely contained within the packet.
  251.    Consequently, a minimum RTP payload size of 261 bytes must be
  252.    supported to contain the largest single header defined in the ES
  253.    (that is, the extension_data() header containing the
  254.    quant_matrix_extension()).  Otherwise, there are no restrictions on
  255.    where headers may appear within packet payloads.
  256.  
  257.    In MPEG, each picture is made up of one or more "slices," and a slice
  258.    is intended to be the unit of recovery from data loss or corruption.
  259.    An MPEG-compliant decoder will normally advance to the beginning of
  260.    next slice whenever an error is encountered in the stream.  MPEG
  261.    slice begin and end bits are provided in the encapsulation header to
  262.    facilitate this.
  263.  
  264.    The beginning of a slice must either be the first data in a packet
  265.    (after any MPEG ES headers) or must follow after some integral number
  266.    of slices in a packet.  This requirement insures that the beginning
  267.    of the next slice after one with a missing packet can be found
  268.    without requiring that the receiver scan the packet contents.  Slices
  269.    may be fragmented across packets as long as all the above rules are
  270.    met.
  271.  
  272.    An implementation based on this encapsulation assumes that the
  273.    Video_Sequence_Header is repeated periodically in the MPEG bit-
  274.    stream.  In practice (though not required by MPEG standard) this is
  275.    used to allow channel switching and to receive and start decoding a
  276.    continuously relayed MPEG bit-stream at arbitrary points in the media
  277.    stream.  It is suggested that when playing back from an MPEG stream
  278.    from a file format (where the Video_Sequence_Header may only be
  279.  
  280.  
  281.  
  282. Hoffman, et. al.            Standards Track                     [Page 5]
  283.  
  284. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  285.  
  286.  
  287.    represented at the beginning of the stream) that the first
  288.    Video_Sequence_Header (preceded by an end-of-stream indicator) be
  289.    saved by the packetizer for periodic injection in to the network
  290.    stream.
  291.  
  292. 3.2 MPEG Audio elementary streams
  293.  
  294.    MPEG1 Audio can be distinguished from MPEG2 Audio from the MPEG
  295.    ancillary_data() header.  For either MPEG1 or MPEG2 Audio, distinct
  296.    Presentation Time Stamps may be present for frames which correspond
  297.    to either 384 samples for Layer-I, or 1152 samples for Layer-II or
  298.    Layer-III.  The actual number of bytes required to represent this
  299.    number of samples will vary depending on the encoder parameters.
  300.  
  301.    Multiple audio frames may be encapsulated within one RTP packet.  In
  302.    this case, an integral number of audio frames must be contained
  303.    within the packet and the fragmentation header defined in Section 3.5
  304.    shall be set to 0.
  305.  
  306.    Also, if relatively short packets are to be used, one frame may be so
  307.    large that it may straddle multiple RTP packets.  For example, for
  308.    Layer-II MPEG audio sampled at a rate of 44.1 KHz each frame would
  309.    represent a time slot of 26.1 msec. At this sampling rate if the
  310.    compressed bit-rate is 384 kbits/sec (i.e.  48 kBytes/sec) then the
  311.    average audio frame size would be 1.25 KBytes.  If packets were to be
  312.    500 Bytes long, then each audio frame would straddle 3 RTP packets.
  313.    The audio fragmentation indicator header (See Section 3.5) shall be
  314.    present for an MPEG1/2 Audio payload type to provide for this
  315.    fragmentation.
  316.  
  317. 3.3 RTP Fixed Header for MPEG ES encapsulation
  318.  
  319.    The RTP header fields are used as follows:
  320.  
  321.         Payload Type: Distinct payload types should be assigned
  322.           for video elementary streams and audio elementary streams.
  323.           See [4] for payload type assignments.
  324.  
  325.         M bit:  For video, set to 1 on packet containing MPEG frame
  326.           end code, 0 otherwise.  For audio, set to 1 on first packet
  327.           of a "talk-spurt," 0 otherwise.
  328.  
  329.         PT:  MPEG video or audio stream ID.
  330.  
  331.         timestamp: 32-bit 90K Hz timestamp representing presentation
  332.           time of MPEG picture or audio frame.  Same for all packets
  333.           that make up a picture or audio frame.  May not be
  334.           monotonically increasing in video stream if B pictures
  335.  
  336.  
  337.  
  338. Hoffman, et. al.            Standards Track                     [Page 6]
  339.  
  340. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  341.  
  342.  
  343.           present in stream.  For packets that contain only a video
  344.           sequence and/or GOP header, the timestamp is that of the
  345.           subsequent picture.
  346.  
  347. 3.4 MPEG Video-specific header
  348.  
  349.    This header shall be attached to each RTP packet after the RTP fixed
  350.    header.
  351.  
  352.  0                   1                   2                   3
  353.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  354. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  355. |    MBZ    |         TR        |MBZ|S|B|E|  P  | | BFC | | FFC |
  356. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  357.                                                 FBV     FFV
  358.  
  359.         MBZ: Unused. Must be set to zero in current
  360.            specification. This space is reserved for future use.
  361.  
  362.         TR: Temporal-Reference (10 bits). The temporal reference of
  363.            the current picture within the current GOP. This value
  364.            ranges from 0-1023 and is constant for all RTP packets of a
  365.            given picture.
  366.  
  367.         MBZ: Unused. Must be set to zero in current
  368.            specification. This space is reserved for future use.
  369.  
  370.         S: Sequence-header-present (1 bit). Normally 0 and set to 1 at
  371.            the occurrence of each MPEG sequence header.  Used to
  372.            detect presence of sequence header in RTP packet.
  373.  
  374.         B: Beginning-of-slice (BS) (1 bit). Set when the start of the
  375.            packet payload is a slice start code, or when a slice start
  376.            code is preceded only by one or more of a
  377.            Video_Sequence_Header, GOP_header and/or Picture_Header.
  378.  
  379.         E: End-of-slice (ES) (1 bit). Set when the last byte of the
  380.            payload is the end of an MPEG slice.
  381.  
  382.         P: Picture-Type (3 bits). I (1), P (2), B (3) or D (4). This
  383.            value is constant for each RTP packet of a given picture.
  384.            Value 000B is forbidden and 101B - 111B are reserved to
  385.            support future extensions to the MPEG ES specification.
  386.  
  387.         FBV: full_pel_backward_vector
  388.         BFC: backward_f_code
  389.         FFV: full_pel_forward_vector
  390.         FFC: forward_f_code
  391.  
  392.  
  393.  
  394. Hoffman, et. al.            Standards Track                     [Page 7]
  395.  
  396. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  397.  
  398.  
  399.            Obtained from the most recent picture header, and are
  400.            constant for each RTP packet of a given picture. None of
  401.            these values are used for I frames and must be set to zero
  402.            in the RTP header. For P frames only the last two values
  403.            are present and FBV and BFC must be set to zero in the RTP
  404.            header. For B frames all the four values are present.
  405.  
  406. 3.5 MPEG Audio-specific header
  407.  
  408.    This header shall be attached to each RTP packet at the start of the
  409.    payload and after any RTP headers for an MPEG1/2 Audio payload type.
  410.  
  411.  0                   1                   2                   3
  412.  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  413. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  414. |             MBZ               |          Frag_offset          |
  415. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  416.  
  417.         Frag_offset: Byte offset into the audio frame for the data
  418.            in this packet.
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hoffman, et. al.            Standards Track                     [Page 8]
  451.  
  452. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  453.  
  454.  
  455. Appendix 1. Error Recovery and Resynchronization Strategies.
  456.  
  457.    The following error recovery and resynchronization strategies are
  458.    intended to be guidelines only.  A compliant receiver is free to
  459.    employ alternative (or no) strategies.
  460.  
  461.    When initially decoding an RTP-encapsulated MPEG Elementary Stream,
  462.    the receiver may discard all packets until the Sequence-header-
  463.    present bit is set to 1.  At this point, sufficient state information
  464.    is contained in the stream to allow processing by an MPEG decoder.
  465.  
  466.    Loss of packets containing the GOP_header and/or Picture_Header are
  467.    detected by an unexpected change in the Temporal-Reference and
  468.    Picture-Type values.  Consider the following example GOP sequence:
  469.  
  470.         In display order: 0B 1B 2I 3B 4B 5P 6B 7B 8P GOP_HDR 0B ...
  471.         In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_HDR 2I ...
  472.  
  473.    Consider also two counters:
  474.  
  475.         ref_pic_temp (Reference Picture (I,P) Temporal Reference)
  476.         dep_pic_temp (Dependent Picture (B) Temporal Reference)
  477.  
  478.    At each GOP beginning, set these counters to the temporal reference
  479.    value of the corresponding picture type. For our example GOP
  480.    sequence, ref_pic_temp = 2 and dep_pic_temp = 0. Keep incrementing
  481.    BOTH counters by unity with each following picture. Ref_pic_temp
  482.    should match the temporal references of the I and P frames, and
  483.    dep_pic_temp should match the temporal references of the B frames.
  484.  
  485.        dep_pic_temp: -  0  1  2  3  4  5  6  7        8  9
  486.    In stream order:  2I 0B 1B 5P 3B 4B 8P 6B 7B GOP_H 2I 0B 1B ...
  487.        ref_pic_temp: 2  3  4  5  6  7  8  9  10  ^    11
  488.                      --------------------------  |    ^
  489.                                 Match            Drop |
  490.                                                       Mismatch
  491.                                                        in ref_pic_temp
  492.  
  493.    The loss of a GOP header can be detected by matching the appropriate
  494.    counter (based on picture type) to the temporal reference value. A
  495.    mismatch indicates a lost GOP header. If desired, a GOP header can be
  496.    re-constructed using a "null" time_code, repeating the closed_gop
  497.    flag from previous GOP headers, and setting the broken_link flag to
  498.    1.
  499.  
  500.    The loss of a Picture_Header can also be detected by a mismatch in
  501.    the Temporal Reference contained in the RTP packet from the
  502.    appropriate dep_pic_temp or ref_pic_temp counters at the receiver.
  503.  
  504.  
  505.  
  506. Hoffman, et. al.            Standards Track                     [Page 9]
  507.  
  508. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  509.  
  510.  
  511.    After scanning to the next Beginning-of-slice the Picture_Header is
  512.    reconstructed from the P, TR, FBV, BFC, FFV and FFC contained in that
  513.    packet, and from stream-dependent default values.
  514.  
  515.    Any time an RTP packet is lost (as indicated by a gap in the RTP
  516.    sequence number), the receiver may discard all packets until the
  517.    Beginning-of-slice bit is set.  At this point, sufficient state
  518.    information is contained in the stream to allow processing by an MPEG
  519.    decoder starting at the next slice boundary (possibly after
  520.    reconstruction of the GOP_header and/or Picture_Header as described
  521.    above).
  522.  
  523. References
  524.  
  525.    [1] ISO/IEC International Standard 11172; "Coding of moving pictures
  526.        and associated audio for digital storage media up to about 1,5
  527.        Mbits/s", November 1993.
  528.  
  529.    [2] ISO/IEC International Standard 13818; "Generic coding of moving
  530.        pictures and associated audio information", November 1994.
  531.  
  532.    [3] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson,
  533.        "RTP: A Transport Protocol for Real-Time Applications",
  534.        RFC 1889, January 1996.
  535.  
  536.    [4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences
  537.        with Minimal Control", RFC 1890, January 1996.
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Hoffman, et. al.            Standards Track                    [Page 10]
  563.  
  564. RFC 2038        RTP Payload Format for MPEG1/MPEG2 Video    October 1996
  565.  
  566.  
  567. Authors' Addresses
  568.  
  569.    Gerard Fernando
  570.    Sun Microsystems, Inc.
  571.    Mail-stop UMPK14-305
  572.    2550 Garcia Avenue
  573.    Mountain View, California 94043-1100
  574.    USA
  575.  
  576.    Phone: +1 415-786-6373
  577.    EMail: gerard.fernando@eng.sun.com
  578.  
  579.  
  580.    Vivek Goyal
  581.    Precept Software, Inc.
  582.    1072 Arastradero Rd,
  583.    Palo Alto, CA 94304
  584.    USA
  585.  
  586.    Phone: +1 415-845-5200
  587.    EMail: goyal@precept.com
  588.  
  589.  
  590.    Don Hoffman
  591.    Sun Microsystems, Inc.
  592.    Mail-stop UMPK14-305
  593.    2550 Garcia Avenue
  594.    Mountain View, California 94043-1100
  595.    USA
  596.  
  597.    Phone: +1 503-297-1580
  598.    EMail: don.hoffman@eng.sun.com
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Hoffman, et. al.            Standards Track                    [Page 11]
  619.  
  620.